[00:04.540 --> 00:09.780]  Hi, I'm Carl Kosher, and this talk is a look inside the 737 Communications Management Unit
[00:09.780 --> 00:14.180]  and some of the interesting things we've learned while reverse engineering systems.
[00:14.260 --> 00:19.460]  But first, the obligatory who am I slide. So I'm a research scientist at the University of
[00:19.460 --> 00:24.700]  Washington, but previously I was a postdoc at UC San Diego, where I did a lot of this work.
[00:24.700 --> 00:29.160]  In general, I'm a low-level system security researcher, so I've worked on things such as
[00:29.160 --> 00:35.840]  RFID systems, looked at enhanced driver's licenses, transit cards, and built some
[00:35.840 --> 00:42.300]  anti-relaying defenses. I also led one of the original car hacking teams, so we were the first
[00:42.300 --> 00:49.160]  to demonstrate a full remote compromise of a vehicle over the internet. I've reverse-engineered
[00:49.160 --> 00:55.920]  wireless SCADA systems involved in power distribution. I've done some proof-of-concept
[00:55.920 --> 01:02.800]  malware against DNA sequencers and analysis pipelines, and I'm also working on wet lab
[01:02.800 --> 01:09.120]  automation systems these days. So of course I'm not doing this work alone. There are a number of
[01:09.120 --> 01:16.180]  people involved in the AEROSEP project, and this project really came out of the previous car hacking
[01:16.180 --> 01:23.860]  research that we did. So of the people listed here, the ones in the top row and listed in orange
[01:23.860 --> 01:31.580]  were part of that original car hacking team. And that project had some pretty big impact.
[01:31.580 --> 01:34.820]  She thinks she's going to be able to stop right at those cones. Let's make sure that she can't,
[01:34.820 --> 01:38.420]  and she's going to drive right through them. We have complete control of that brake. All right,
[01:38.420 --> 01:46.300]  there we go. Oh no, no, no, no, no, no, no, no, no, no. Brakes didn't work, right? Oh my god,
[01:46.300 --> 01:51.960]  I can't operate the brakes at all. Oh my word, that is frightening.
[01:53.480 --> 01:59.200]  So obviously these results were pretty impactful, and inspired DARPA's approximately 70 million
[01:59.200 --> 02:05.860]  dollar high assurance cyber military systems, or HACMS program, to make systems provably secure
[02:05.860 --> 02:11.920]  against attack. But avionic systems are already engineered to a high assurance level, albeit for
[02:11.920 --> 02:19.400]  safety, not security. So we wondered if these safety assurance requirements translated into
[02:19.400 --> 02:28.080]  improved security. So the 777, 787, and A380 all have new and interesting architectures,
[02:28.080 --> 02:35.720]  but you can't really buy spare parts for those off of eBay. As it turns out, as 737 airframes are
[02:35.720 --> 02:42.000]  retired, parts do become available from auction sites, and so that's why we decided to focus on
[02:42.000 --> 02:48.760]  737s. And there's actually a great website with a ton of information about the 737 that we used in
[02:48.760 --> 02:54.400]  our research, and they've even released a book. After investigating how the systems were integrated,
[02:54.400 --> 02:59.180]  we decided to focus on the communications management unit, as it connects the rest of
[02:59.180 --> 03:08.240]  the avionic systems to the outside world. So for example, the CMU can take messages through the VHF,
[03:08.240 --> 03:14.500]  HF, or satellite radios, and relay them to other avionic systems. It's also used for sending
[03:14.500 --> 03:20.940]  messages between pilots and ground. So since the CMU is sort of this central hub for all this
[03:20.940 --> 03:26.240]  messaging, it has a pretty large attack surface, and it's a pretty juicy target for looking for
[03:26.240 --> 03:33.300]  vulnerabilities. So aside from the display unit, all these systems live in the electronics and
[03:33.300 --> 03:40.720]  equipment bay. This is a view from the E&E bay from the outside, and this is what it looks like from
[03:40.720 --> 03:49.100]  the inside. So all of these boxes are called LRUs, or line replaceable units, because they slide in
[03:49.100 --> 03:55.140]  and out and connect with an interconnect backplane, making them very easy to swap out for maintenance
[03:55.140 --> 04:01.740]  or repair. So in the cockpit, pilots interact with these systems through these control display units.
[04:01.740 --> 04:08.000]  Originally, there were separate display units for messaging and for the flight management system,
[04:08.000 --> 04:13.700]  but they've since been combined into these multi-control display units, or NCDUs, where you can
[04:13.700 --> 04:19.880]  access different systems through one common interface. So for example, on the left, the MCDU
[04:19.880 --> 04:26.200]  is interacting with the flight management system, while on the right, the MCDU is interacting with
[04:26.200 --> 04:32.400]  the communications management unit, which allows the pilots to send and receive messages, request
[04:32.400 --> 04:39.420]  weather reports, do a whole bunch of things. So to put the communications management unit in context,
[04:39.420 --> 04:44.880]  we first need to talk about ACARS, which started out as a simple messaging system
[04:44.880 --> 04:51.180]  designed to solve one very specific problem for airlines, and that was ensuring that they paid
[04:51.180 --> 04:58.360]  their employees only as much as they were entitled to. And the way that it did this is through
[04:58.360 --> 05:07.820]  reporting these OOOI statuses, which basically indicates whether the plane is out of the gate,
[05:07.820 --> 05:13.380]  off the ground, on the ground, or back in the gate. And this is how airlines determine
[05:13.380 --> 05:18.560]  how pilots and flight attendants are paid. But since then, it's been generalized to transfer
[05:18.560 --> 05:25.520]  avionics data. So for example, you can push a flight plan over ACARS, or you can request a
[05:25.520 --> 05:31.120]  clearance from air traffic control. Airlines typically have their own applications that they
[05:31.120 --> 05:36.780]  add on top of this. So for example, if you've ever received connecting gate information while you're
[05:36.780 --> 05:42.460]  in flight, that information was likely relayed through ACARS, and it's increasingly being used
[05:42.460 --> 05:49.180]  to replace traditional voice-based air traffic control communications, especially in Europe.
[05:49.180 --> 05:56.040]  So ACARS works over multiple RF link types, including the legacy VHF ACARS radios,
[05:56.040 --> 06:04.680]  the new VHF VDL2 data radios, over the horizon HF data radios, and even satellite links. And
[06:04.680 --> 06:10.300]  since this standard came out in 1978, and has largely been unchanged since then, these messages
[06:10.300 --> 06:17.480]  typically aren't encrypted. And when they are, they're often encrypted using questionable methods.
[06:18.000 --> 06:21.910]  So the communications management unit has some interesting requirements.
[06:22.300 --> 06:27.480]  So obviously, air traffic control is flight critical, and so that software needs to be
[06:27.480 --> 06:33.340]  certified to a certain assurance level. But airlines want to add their own custom apps to
[06:33.340 --> 06:39.000]  these communication management units. And it's cost prohibitive and extremely time intensive
[06:39.000 --> 06:46.880]  to certify these. So how do CMUs allow uncertified apps to not taint certification?
[06:47.620 --> 06:54.320]  As it turns out, there are two major vendors of CMUs for the SEM37, and they each take
[06:54.680 --> 07:02.280]  a different approach to solving this problem. So the two major versions of the CMU for the SEM37
[07:02.280 --> 07:11.580]  are the Collins CMU-900 and the Honeywell Mk3. So the Collins CMU-900 has 46 for running applications,
[07:11.580 --> 07:17.360]  386 to handle IO, and does inter-process communication through dual-ported RAM between
[07:17.360 --> 07:23.000]  the two processors. It runs the Vertex real-time operating system, which I'll talk a little bit
[07:23.000 --> 07:31.720]  about later. Makes extensive use of x86 segments, which makes reverse engineering a giant pain.
[07:31.720 --> 07:36.660]  And they invented their own virtual machine instruction set that apps are compiled for,
[07:36.660 --> 07:42.420]  and this allows apps to be isolated without tainting certification. The other major player
[07:42.420 --> 07:48.620]  is the Honeywell Mk3, and it has a slightly beefier Pentium for running its applications,
[07:48.620 --> 07:55.380]  and uses PowerPC to handle IO. And similar to the CMU-900, it uses dual-ported RAM for
[07:55.380 --> 08:02.280]  inter-processor communication. However, the Pentium runs Honeywell's custom DOS real-time
[08:02.280 --> 08:10.720]  operating system, while the PowerPCs use Vertex, like the CMU-900. On the Honeywell Mk3, apps are
[08:10.720 --> 08:15.440]  database-driven, and the database processing code is written in a verifiable language
[08:15.440 --> 08:19.860]  that I'll describe later. So let's take a look inside some of these units.
[08:19.860 --> 08:27.480]  So this is the CMU-900 main processor board, and on there you have the 486, RAM, a CPLD for glue
[08:27.480 --> 08:33.980]  logic, a timer and interrupt controller, a real-time clock, and a serial interface chip.
[08:34.240 --> 08:42.160]  The IO board is responsible for interfacing with all the 429 buses. On the board we have the 386,
[08:42.160 --> 08:48.600]  the dual-ported RAM, and some custom ASICs that we're pretty sure are 429 transceivers,
[08:48.600 --> 08:53.080]  along with some analogy bits to interface with the 429 bus.
[08:53.900 --> 08:59.860]  So this is the Honeywell Mk3 processor board, and underneath that heatsink is a Pentium.
[08:59.860 --> 09:06.460]  There's also RAM, some glue logic, and a very annoying non-volatile storage system,
[09:06.460 --> 09:12.320]  which relies on a battery, which of course has gone dead by now, basically breaking the system.
[09:12.880 --> 09:19.360]  So the IO board on the Honeywell Mk3 is a rather interesting beast. The first thing that pops out
[09:19.360 --> 09:24.540]  to me is that there are two PowerPCs, and through our reverse engineering, it seems like only one
[09:24.540 --> 09:30.540]  of them is used for IO, while the second supports reflashing the system. So in the middle there is
[09:30.700 --> 09:38.060]  a CPLD, which we suspect interfaces the 429 transceivers with the PowerPC chips. There are
[09:38.140 --> 09:43.060]  a number of interesting connectivity options on here. So for example, there's an Ethernet
[09:43.060 --> 09:50.240]  controller on there with magnetics, probably for supporting a gate link upgrade, whereby you can
[09:50.240 --> 09:59.580]  push messages to the CMU over Wi-Fi. There's also a DSP chip next to an ADC, and we suspect that's
[09:59.580 --> 10:07.840]  used for sending ACARS messages over legacy VHF radios. But also interestingly enough, there's a
[10:07.840 --> 10:15.600]  V.90 modem chipset, and I'm not really sure why this exists, especially with that other DSP chip
[10:15.600 --> 10:22.660]  on there. Perhaps they were leaving the option open to plug a CMU into a phone line. Not really
[10:22.660 --> 10:28.800]  sure that would make sense on an aircraft, but it might make sense for maintenance.
[10:29.780 --> 10:36.340]  And of course, there's lots of JTAG connectors everywhere. It warms my heart. So let's take a
[10:36.340 --> 10:43.620]  deep dive into how the Honeywell Mk3 is actually constructed. So to begin our reverse engineering
[10:43.620 --> 10:49.500]  journey, we sacrificed one board, removed the conformal coding, pulled off the flash chips,
[10:49.500 --> 10:55.720]  dumped the flash chips, and ran strings on the binaries. And what we saw next was surprising.
[10:56.680 --> 11:05.440]  This program must be run under Win32. Wow. By looking for PE headers, we were able to carve
[11:05.440 --> 11:11.180]  the flash ROM into a number of interesting files. It also turns out the flash had multiple
[11:11.180 --> 11:17.920]  partitions. One seemed to be for flight mode, another seemed to be for update mode, and another
[11:17.920 --> 11:25.940]  for recovery. So as it turns out, Honeywell wrote their own realtime OS called DOS. And one of the
[11:25.940 --> 11:31.800]  interesting things about DOS is that its scheduler was ported to Java and formally verified by NASA
[11:31.800 --> 11:36.880]  to ensure that it always met its realtime requirements. As you might have guessed,
[11:36.880 --> 11:43.120]  it seems heavily inspired by Windows. It loads statically linked portable executables.
[11:43.200 --> 11:51.340]  The APIs look a lot like Win32 or the Windows NT kernel API. And in fact, while reverse engineering
[11:51.340 --> 11:57.380]  the kernel, if I didn't know what a parameter to a function was, I would just go to MSDN,
[11:57.380 --> 12:04.540]  and it would probably have the right answer. And it even has a concept of a registry,
[12:04.540 --> 12:09.540]  which is basically just a small binary blob of configuration parameters.
[12:10.080 --> 12:16.180]  So why is DOS so similar to Windows? Is it because they wanted to develop the CMU code
[12:16.180 --> 12:22.780]  against a Windows target? Well, this is pure speculation, but here's a map of Microsoft
[12:22.780 --> 12:32.500]  campus in Redmond, Washington. And right across the street is Honeywell Aerospace. So again,
[12:33.020 --> 12:39.680]  just speculation, but I'm guessing it was likely developed by ex-Microsoft employees.
[12:40.500 --> 12:47.400]  So outside of the kernel, the bulk of the CMU code is in a single executable called CMU core.
[12:47.400 --> 12:53.760]  And this is written in a language called SDL, the Specification and Description Language.
[12:53.760 --> 13:00.460]  And this was created by the ITU. And it is a language that only telecoms can love.
[13:00.460 --> 13:06.540]  Data structures are defined by ASN 1, and basically it's intended for building telephone
[13:06.540 --> 13:13.460]  switches. If you're familiar with Erlang, it's spiritually similar. SDL lets you define loosely
[13:13.460 --> 13:19.160]  coupled state machines that pass messages to each other. So it's ideal for protocol handling.
[13:19.920 --> 13:25.680]  SDL has a couple of forms that it can take. There is both a graphical and a textual form.
[13:25.720 --> 13:31.920]  The graphical form is shown here. So basically you write state machines that send and receive
[13:31.920 --> 13:38.260]  messages or are triggered by timers. And you can also execute arbitrary C code.
[13:38.860 --> 13:45.880]  Now there's a companion language to SDL called MSC, or Message Sequence Charts. And this lets
[13:45.880 --> 13:52.200]  you define protocol flows and test cases to validate your SDL against. And by writing test
[13:52.200 --> 13:58.720]  cases for handling 429 and ACARS messages, they can verify that the SDL code is correct.
[13:58.980 --> 14:04.260]  So like I said, SDL programs are composed of loosely coupled state machines called tasks.
[14:04.260 --> 14:10.260]  And in CMU Core, there are a lot of tasks. And many of them send messages to each other.
[14:10.400 --> 14:15.200]  Now, I'm not going to read through this entire list here, but I encourage you to pause the video
[14:15.200 --> 14:22.340]  and take a look at the list. So at this point, we have SDL code that is verified. And that SDL
[14:22.340 --> 14:28.720]  code is then compiled down to C code by a product called ObjectGeode, which was made by a company
[14:28.720 --> 14:34.860]  named, confusingly enough, Verilog. No relation to the hardware description language.
[14:34.860 --> 14:40.880]  But how do airlines make their own apps? Well, it turns out that the SDL code actually reads
[14:40.880 --> 14:47.820]  app logic from databases stored in Flash. So I'm sure you've all heard of SQL, but there's also
[14:47.820 --> 14:54.040]  another database language called QWEL. And the database on the Honeywell Mark 3 is an embedded
[14:54.040 --> 15:01.020]  version of Ingress QWEL. Now, the crazy thing is that queries are directly embedded in C files,
[15:01.020 --> 15:06.020]  which are then preprocessed into other C files, which are then compiled and linked against.
[15:06.680 --> 15:11.700]  So if you want to write a query that iterates through employee names, you can write it sort of
[15:11.700 --> 15:18.700]  as a pseudo for loop, as shown here. And that will be turned into a database query, and that printf
[15:18.700 --> 15:25.280]  will be executed for every row returned. So unfortunately, these queries are directly
[15:25.280 --> 15:31.000]  converted into C code, so there are no query strings in the executable. And furthermore,
[15:31.000 --> 15:36.200]  we don't even have any schema information, since it's known at compile time, so there is no reason
[15:36.200 --> 15:43.760]  to store it in Flash. So how are these apps created? Well, Honeywell has this tool called
[15:43.760 --> 15:51.300]  the Ground-Based Software Tool, which is used both to create HGI, the Honeywell-generated
[15:51.300 --> 15:59.160]  information, as well as the AMI, or the Airline Modifiable Information. And basically, this tool
[15:59.160 --> 16:06.160]  lets you populate the database tables that define your app. And this is used both for
[16:06.160 --> 16:12.040]  certified apps made by Honeywell, as well as custom operational apps made by airlines.
[16:13.000 --> 16:19.080]  So how do these state machines actually interact with real hardware? Well, these SDL messages are
[16:19.080 --> 16:26.500]  serialized and sent through DOS's inter-process communication mechanism, mailboxes, to a process
[16:26.500 --> 16:33.820]  called DP-RAM-IO. And DP-RAM-IO takes these messages and shoves it into the dual-ported RAM,
[16:33.820 --> 16:41.280]  which is shared by the PowerPCs. And the PowerPCs handle the low-level interface to the hardware.
[16:41.280 --> 16:49.560]  So as I said before, one seems to handle the PCMCI update cards and does little else. The
[16:49.560 --> 16:55.400]  other one seems to handle almost everything. Unlike the Pentium chip, the PowerPCs run the
[16:55.400 --> 17:02.900]  Vertex real-time OS. And the code on the PowerPCs is also written in SDL. So this makes it fairly
[17:02.900 --> 17:11.000]  easy to pass messages back and forth between the x86 and PowerPCs. So Vertex is a fairly old,
[17:11.000 --> 17:17.320]  but well-proven real-time operating system. And to emphasize this point, here's an ad from 1983,
[17:17.320 --> 17:22.120]  where they will buy you a VW bug if you find a bug in their OS.
[17:23.960 --> 17:28.980]  So there's one tricky bit about passing messages between the x86 and PowerPC.
[17:29.440 --> 17:36.860]  And that is x86 is little-endian, while PowerPC is big-endian. And so the way that they actually
[17:36.860 --> 17:43.020]  solve this is with one giant switch statement based on the message type to do the endianness
[17:43.020 --> 17:50.200]  swap. And that code is written in C, which of course is far more promising for bugs.
[17:51.000 --> 17:57.880]  And in fact, we found some. So we found some signed versus unsigned confusion and some integer
[17:57.880 --> 18:04.700]  overflows as well. Fortunately, they do not seem to be exploitable. So now that we have a general
[18:04.700 --> 18:10.520]  idea of how the CMU works, let's actually try going and see if we can find some real bugs.
[18:11.100 --> 18:17.740]  So static analysis of this auto-generated code is hard. So we'd like to do some dynamic analysis.
[18:18.220 --> 18:25.540]  Unfortunately, getting the CMU to boot was challenging. It does a lot of self-tests on
[18:25.540 --> 18:32.240]  startup. If something is wrong, it just won't boot. And we spent several months with it just
[18:32.240 --> 18:38.840]  blinking the fail light at us. Fortunately, we found some serial ports on the front maintenance
[18:38.840 --> 18:44.780]  port, which gave us some clues as to what was going wrong. So when we powered up the CMU,
[18:44.780 --> 18:50.340]  it would state that it was starting its built-in functional test. Unfortunately, after a minute,
[18:50.340 --> 18:56.720]  it would start spitting out error codes. And as it turns out, this was because the APM was missing.
[18:56.720 --> 19:04.500]  Now the APM is the airline personality module, which has the tail number, the aircraft configuration,
[19:04.500 --> 19:09.820]  the type of aircraft it is, and a host of other settings. So if you need to replace the CMU,
[19:09.820 --> 19:16.160]  you don't have to reprogram it. You just pull it out, slide in a new one, connects to the existing
[19:16.160 --> 19:22.880]  airplane personality module, and the new CMU knows exactly what it needs to do. Unfortunately,
[19:22.880 --> 19:30.580]  the only APM we could find was for the Collins CMU-900, which despite being somewhat specified
[19:30.580 --> 19:38.740]  by an airing standard, was totally incompatible, both logically and electrically. Fortunately,
[19:38.740 --> 19:46.240]  the CMU saves a copy of the last known good APM image in Flash. And so we were actually able to
[19:46.240 --> 19:53.120]  create an APM emulator with an Arduino. It basically just emulated an i-squart-z EEPROM,
[19:53.120 --> 19:58.560]  and we used the APM image that we pulled out of Flash. Now the second issue that we ran into
[19:58.560 --> 20:05.940]  was NVRAM battery was bad, and we didn't actually know that this was preventing the CMU from booting.
[20:06.360 --> 20:11.320]  We basically had to take one of the cryptic error codes out of the serial console,
[20:11.320 --> 20:18.220]  find where that was in the binary, figure out what triggered that string to be printed,
[20:18.220 --> 20:24.580]  and then discover that it was doing a test on the battery voltage. As it turns out, we just
[20:24.580 --> 20:29.960]  removed the battery and replaced it with a power supply, and that was good enough to make it boot.
[20:30.400 --> 20:35.260]  So there was actually a second serial port exposed on the front maintenance port.
[20:35.260 --> 20:42.000]  And once the system booted, if you pressed enter, you got an interesting maintenance menu.
[20:42.200 --> 20:48.100]  Another weird behavior is that if you provided input to the first serial port,
[20:48.100 --> 20:55.740]  you would get another menu on the second serial port. So now that we can get the CMU to boot,
[20:55.740 --> 21:03.200]  let's try doing something with it. And to do that, we need an MCDU and a VHF data radio.
[21:03.200 --> 21:08.280]  Unfortunately, we didn't have those, so we ended up writing emulators for them and connected them
[21:08.280 --> 21:15.880]  to the real CMU over the 429 buses. And this really kicked off the development of a test bed
[21:15.880 --> 21:23.680]  we called Triton to support this kind of testing and security research. So the Triton test bed is
[21:23.680 --> 21:30.740]  designed to support a mixture of both real and emulated devices. So for example, we have a real
[21:30.740 --> 21:37.580]  communications management unit, but we don't have a real printer or airborne data loader unit.
[21:37.580 --> 21:44.840]  So we've created emulators for those. And these devices are connected through a 429 message
[21:44.840 --> 21:54.340]  routing daemon, which we call R429D. And R429D both supports real 429 interfaces, as well as
[21:54.340 --> 22:00.360]  accepting connections from emulated avionics units. Similarly for ACARS, we have a separate daemon
[22:00.360 --> 22:06.880]  that emulates different network segments. For example, we have one daemon that emulates the
[22:06.880 --> 22:13.560]  air segment, so all the VHF data radios are connected to it. We also have a separate instance
[22:13.560 --> 22:18.500]  for the ground segment, and we have a virtual ground station that bridges the two segments.
[22:19.920 --> 22:25.120]  So a little bit about the 429 devices that the Triton test bed supports.
[22:25.120 --> 22:30.980]  This box here is an Ethernet to 429 converter, and this was one of the first things that we
[22:30.980 --> 22:36.660]  targeted. Unfortunately, it can only be configured with a static IP address,
[22:36.660 --> 22:41.920]  and it kept getting virtually bricked by having its IP address randomly changed to something
[22:41.920 --> 22:50.240]  that we didn't know. And we actually suspect that UCSD was doing network scans against this device,
[22:50.240 --> 22:56.460]  and it just so happened that it sent a packet to reconfigure the IP address to some garbage
[22:56.460 --> 23:02.620]  address. So after a couple of times of opening this up, pulling off the EEPROM, putting in the
[23:02.620 --> 23:07.560]  correct IP address, soldering it back on, getting it back on the network, only to have it bricked
[23:07.560 --> 23:13.540]  again, we decided to find a better solution. One of the primary interfaces that we use now
[23:13.540 --> 23:20.120]  is this Ballard USB to 429 interface. Unfortunately, it is rather expensive.
[23:20.600 --> 23:27.400]  We did also develop our own custom USB to 429 interface, which we called Scorpion.
[23:27.400 --> 23:34.040]  And if you ever saw the pilot episode of that TV show, you might understand why we called it that.
[23:34.040 --> 23:42.400]  It's basically an ATmegaU2 with a Holt 429 transceiver. It supports four transmit channels
[23:42.400 --> 23:50.080]  and eight receive channels. And this basically interfaces with the R429D daemon to expose a
[23:50.080 --> 23:56.900]  TCP IP interface to the 429 buses. So now that we have all this wired up,
[23:56.900 --> 24:02.980]  we can start doing some really interesting things. So on the left here, we have our virtual MCDU,
[24:02.980 --> 24:11.740]  which lets us control our real CMU. Now connected to the real CMU is our virtual VHF data radio,
[24:11.740 --> 24:18.280]  which we can send real ACARS messages that we pick off over the air, alter the tail number so
[24:18.280 --> 24:24.580]  that our CMU processes them, which then forwards it to our virtual printer program, which sends
[24:24.580 --> 24:40.250]  it to a real credit card receipt printer. So interacting with the CMU is all well and good,
[24:40.250 --> 24:45.210]  but we'd really like to have some low-level debugging capabilities. And as it turns out,
[24:45.210 --> 24:51.830]  the main processor board has a Pentium debug port. Now, unfortunately, the Pentium Probe mode
[24:51.830 --> 25:00.090]  is undocumented. Details are in the infamous Appendix H of the P5 external interface specification,
[25:00.090 --> 25:06.030]  which was available only under NDA from Intel. And back in the mid-90s, there were a lot of
[25:06.030 --> 25:11.830]  rants in Dr. Dobbs' journal about this. There was one beta version of the P5 external interface
[25:11.830 --> 25:17.430]  specification that had these details, but all these copies were supposedly recalled by Intel
[25:17.430 --> 25:23.490]  and destroyed. So, of course, there's no copies of this on the web. But while we were searching
[25:23.490 --> 25:30.430]  for it, we did find that there was one physical copy of an unknown version at an undisclosed
[25:30.430 --> 25:37.810]  university lab halfway across the world. So we sent them an email and asked if they had it,
[25:37.810 --> 25:44.010]  and if so, what version it was, and that we might be interested in a scan of it.
[25:44.210 --> 25:51.730]  And so they wrote back with a scan of the title page, which was version 1.3. And unfortunately,
[25:51.730 --> 25:57.250]  we needed version 3. So before we could write them back and say thanks, but no thanks,
[25:57.250 --> 26:02.670]  they wrote us back and said they found something very interesting inside. And sandwiched between
[26:02.670 --> 26:11.050]  the pages of version 1.3 was version 3. And they happened to send us a scan of the entire thing,
[26:11.050 --> 26:16.270]  including details of the Pentium micro-op instruction format, which is exactly what
[26:16.270 --> 26:22.190]  you need to use the Pentium's probe mode. So armed with this information, I added P5
[26:22.190 --> 26:28.810]  debugging support to OpenOCD. And so now we can use GDB against the CMU. Unfortunately,
[26:28.810 --> 26:33.490]  if you halt the hardware, the watchdog timers on the other processors will notice something's
[26:33.490 --> 26:39.790]  amiss and reset the entire system. And the solution for this is to basically run the CMU's
[26:39.790 --> 26:48.350]  x86 firmware in QMU, but relaying messages to the power PCs over JTAG. And this is based on
[26:48.350 --> 26:53.870]  some of my earlier dissertation work on a system called Surrogates, which lets you run firmware
[26:53.870 --> 27:00.530]  in QMU, but proxies peripheral access over JTAG in near real time. So now we can instrument the
[27:00.530 --> 27:06.870]  CMU firmware, collect IO traces, do snapshots, and do all sorts of interesting dynamic analysis.
[27:07.610 --> 27:12.370]  So in summary, the communications management unit supports flight critical operations,
[27:12.370 --> 27:19.010]  which requires the firmware to be certified. But airlines desire customization. And through
[27:19.010 --> 27:25.430]  our reverse engineering, we've identified some somewhat unusual ways that vendors have isolated
[27:25.430 --> 27:31.930]  these uncertified apps from the rest of the certified system. And finally, we built a flexible
[27:31.930 --> 27:37.910]  testbed for further security research on avionic systems. So if you would like more information
[27:37.910 --> 27:44.590]  about our Triton testbed or surrogate system, check out our site at aerosec.org. Thanks!
